7017 Carriage CARRIAGE: Carriage state error. Current state: <description>, jog_count = <n> JOG = <number> PLOT = <number> All This error replaces the more cryptic error "Unexpected error: 0x<nn>" with a more informative message (carriage module V2.10). Ok, so it's still cryptic but it's got more information useful to firmware programmers. This error message will spring up whenever the state machine hits an invalid state, i.e. the carriage firmware is confused. This could be due to a slew of reasons such as: various hardware failures (ALE or MPE) firmware bug firmware interrupt latencies caused by things like misbehaving SCSI, for example. psteps too big for given drum circumference and dpi Now in practice, that last one is the most common cause of the error. Just reduce psteps and the error should go away. The magic calculation is: max psteps = TRUNC( (dpi * diam) / 16558 ) - 1 where TRUNC is the truncated (rounded down) result, "dpi" is the resolution in dots per inch, and diam is the drum diameter in mm (same as the drum diam parameter). So for a 3244 machine at 1600 dpi, psteps can be set up to 26. Note that a machine may have its psteps set less than this maximum value which is fine as long as the carriage doesn't stall. If the machine is to be run at a number of different resolutions, then pick the lowest resolution for calculating psteps. Remember that psteps simply sets the number of steps (increments) the firmware uses to accelerate and decelerate the carriage for plotting (not for general carriage moves, that's done differently). This means that if psteps is chosen according to the lowest dpi and the carriage doesn't ever stall when plotting, it's set just fine. If the error persists, capture a log file of the diagnostic output for the machine and forward it to the product's TTE. Be sure to use the "carriage trace" command immediately after the plot is complete, which will dump out the most recent run history of the carriage firmware. Click on CANCEL IMAGE. If the machine does not recover, turn the power to the output machine off and on again. Please contact Creo Service to report this error. Carriage psteps set too high. Note that the machine might work fine for most plots and only die with this error when a retrace occurs. DPI set too low, or the image requested a lower DPI than the machine is set up to handle. Either increase the dpi or adjust the psteps. SCSI interrupts bogging down machine. There was a bug of some kind in the TIFF downloader, but this should have been fixed by now (02/14/01). If the problem only occurs with workstation-generated plots but not with manual test plots (with the same resolution), then blame the workstation SCSI. Firmware bug. You know the routine. Xilinx file bug (requires updated firmware) MPE or ALE problem (hasn't happened yet, but it's possible). ../nvs/carriage_cfg_psteps.xmlNVS: carriage psteps ../nvs/drum_cfg_diam.xmlNVS: drum diam ../commands/carriage_trace.xmlCommand: carriage trace ..\..\ShowAllErrors.htmFirmware 0 Error Index ..\..\ShowAllCommands.htmFirmware 0 Command Index ..\..\ShowAllNVS.htmFirmware 0 NVS Index Updated: Wed Jul 16 19:32:29 2008 PST